…as split

The inherited dashpay#4172 instrumented tests hardcode the legacy KEYS_ALIAS and
the single-alias API; after the alias split the default-policy storage
writes under KEYS_ALIAS_AUTH_GATED, so simulating keypair replacement by
deleting the legacy alias no longer invalidates anything (the CI failure
shumkov diagnosed on storeIfAbsentRederivesWhenTheKeysAliasKeypairWasReplaced).

- WalletStorageOwnershipTest: the replaced-keypair, rejected-blob, and
  no-regeneration probes delete/inspect KEYS_ALIAS_AUTH_GATED; the
  fingerprint-capture test uses encryptForIdentityKeysAlias (and pins the
  captured producing alias); the stale-invalidation-cleanup test uses the
  alias-parameterized deleteIdentityKeysAliasIfCurrentGeneration.
- KeystoreSignerInstrumentedTest: canSignWith rejection simulates
  replacement of the policy alias.

The five DashPayUnlockAndSyncTest / WalletManagerRoundTripTest failures
from PR dashpay#4183's CI run were NOT test or SDK defects: the branch predated
dashpay#4172's workflow hardening (screen_off_timeout / stayon / dismiss-keyguard
+ the hard deviceLocked=0 guard), so the emulator re-locked mid-run and
every MASTER_ALIAS operation threw InvalidKeyException. Rebuilding on the
current base inherits the fixed workflow; those tests are unchanged.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…otFound

Split out of dashpay#4183 (port of dashpay#4060) per review: the
unmanaged-identity read fixes are conflict-free on v4.1-dev and should
not be blocked on the Keystore rework.

The FFI's blanket Option -> result conversion reports an identity the
wallet does not manage as PlatformWalletFFIResultCode::NotFound (98),
so the Kotlin callers' zero-handle checks were dead and every local
read over an unmanaged identity threw instead of returning absence.

- Dashpay: route getManagedIdentity through
  translateManagedIdentityNotFoundToZero so contacts()/syncState()/
  payments()/sendContactRequest() treat "not managed" as null/empty/
  false; ErrorInvalidHandle still propagates.
- Sweep the remaining dead `== 0L` sites: ManagedPlatformWallet
  .inMemoryIdentityStates (one unmanaged/just-removed id no longer
  throws through the whole listing) and IdentityRegistration
  .contestedDpnsNames (the intended "identity is not managed by this
  wallet" NotFound now actually surfaces).
- platform-wallet-ffi: platform_wallet_get_managed_identity keeps the
  three outcomes distinct (classify_managed_identity_outcome) so a
  stale/removed wallet surfaces ErrorInvalidHandle and never
  masquerades as an unmanaged identity; unit tests pin both arms.
- DashSdkError: name the code (PLATFORM_WALLET_NOT_FOUND_CODE = 98);
  the 98 -> DashSdkError.NotFound mapping is unchanged.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Split out of dashpay#4183 (port of dashpay#4060) per review: the
typed signing error is conflict-free on v4.1-dev and should not be
blocked on the Keystore rework.

The KeystoreSigner "missing key" completion error travels as free text
through Rust and used to come back as an opaque PlatformWallet.Generic
(or WalletOperation) failure. It is now built from a shared
MESSAGE_MARKER constant and recognized on the Kotlin boundary as the
typed DashSdkError.PlatformWallet.SigningKeyUnavailable, so hosts can
route users to key repair instead of showing a generic error. The
marker is only consulted on the catch-all codes (6 / else), so the
dedicated retry-semantics types are never overridden.

Known limitation (kept as-is from dashpay#4183 by request): the discriminator
is message-text-based (message.contains on the marker); a structured
error code across the FFI boundary is follow-up work in the parent PR
line.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…as split

The inherited dashpay#4172 instrumented tests hardcode the legacy KEYS_ALIAS and
the single-alias API; after the alias split the default-policy storage
writes under KEYS_ALIAS_AUTH_GATED, so simulating keypair replacement by
deleting the legacy alias no longer invalidates anything (the CI failure
shumkov diagnosed on storeIfAbsentRederivesWhenTheKeysAliasKeypairWasReplaced).

- WalletStorageOwnershipTest: the replaced-keypair, rejected-blob, and
  no-regeneration probes delete/inspect KEYS_ALIAS_AUTH_GATED; the
  fingerprint-capture test uses encryptForIdentityKeysAlias (and pins the
  captured producing alias); the stale-invalidation-cleanup test uses the
  alias-parameterized deleteIdentityKeysAliasIfCurrentGeneration.
- KeystoreSignerInstrumentedTest: canSignWith rejection simulates
  replacement of the policy alias.

The five DashPayUnlockAndSyncTest / WalletManagerRoundTripTest failures
from PR dashpay#4183's CI run were NOT test or SDK defects: the branch predated
dashpay#4172's workflow hardening (screen_off_timeout / stayon / dismiss-keyguard
+ the hard deviceLocked=0 guard), so the emulator re-locked mid-run and
every MASTER_ALIAS operation threw InvalidKeyException. Rebuilding on the
current base inherits the fixed workflow; those tests are unchanged.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…re (dashpay#4183)

The repair path derived the KEYPAIR and required its public half to equal the
key's stored on-chain data before persisting. For ECDSA_HASH160 /
EDDSA_25519_HASH160 keys DPP stores the 20-byte HASH160 of the pubkey as that
data, not the pubkey, so the raw 33-vs-20-byte contentEquals could never match
and those key types were permanently un-repairable.

derivedPublicKeyMatches now takes the DPP key-type discriminant and HASH160s the
derived pubkey (RIPEMD160(SHA256)) before comparing for HASH160 types; every
other type keeps the plain content comparison. keyType is threaded through
PrivateKeyDeriver.deriveAndStore; the repair path reads it from the persisted
row's breadcrumbs, the store path passes it from the persist callback. Adds a
pure-Kotlin Hash160 helper (public bytes only — no derivation/secrets, within
the CLAUDE.md doctrine) pinned to RIPEMD-160 reference vectors, and tests
proving a HASH160-type key repairs.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Resolves the two blocking review findings and the live suggestions on dashpay#4261.

Blocking — advance dashpay#3968's reissue frontier to 38. Code 37 is allocated to
dashpay#4204, so the branch-specific guidance in the non-conforming section and in
the 27/28 detail section could still have sent dashpay#3968 to 37 and recreated the
collision with ErrorShieldedInviteAlreadyClaimed. Both references now say
38+, and both state that the reserved 28 and 30 are not available either.

Blocking — 28 and 30 were labelled RESERVED in the table and the frontier
paragraph but "free" in the code-30 section and the collision history. Rule 1
lets a contributor claim a gap this file marks free, so the two labels gave
two different allocation frontiers. Everything now says reserved-not-free and
cites rule 1 explicitly.

Open-PR inventory: verified 2026-08-03 against each PR's file list and the
error.rs at its head. Adds dashpay#3417, dashpay#3549, dashpay#3992 and dashpay#4243 (all touch the crate
without claiming an integer; dashpay#4243 maps new wallet errors onto the existing
ErrorInvalidParameter). Removes dashpay#4240 and dashpay#4251, whose heads touch no file
under this crate; removes dashpay#4258, merged on 2026-08-03; records dashpay#4264 as
closed with its work carried by dashpay#4243.

Also in this pass:

- dashpay#4204's Swift mirror is recorded as PARTIALLY fixed. At d78b940 the raw
  case and its init(ffi:) arm exist, but PlatformWalletError has no typed case
  and its exhaustive init(result:) has no arm, so the Swift package does not
  compile as written. Rule 5's Swift clause is not yet satisfied there.
- The preamble no longer claims duplicate discriminants are always silent. Two
  different names on one integer is an E0081 after a merge (that is how the
  code-32 collision surfaced); the silent case is a meaning moving to a new
  integer, or an un-updated host mirror.
- Code 13 ErrorArithmeticOverflow does have an in-tree producer
  (shielded_send.rs); the row said it had none.
- dashpay#3968 is no longer described as simply un-rebased: its head does contain the
  2026-08-01 base, it is behind the current base, and a rebase alone fixes
  nothing because git sees no conflict — the branch must edit its own enum.
- Provenance re-read on 2026-08-03 from GitHub rather than carried forward,
  now as a table with a note per PR. dashpay#4183 and dashpay#4184 were rebased onto
  5d68612 today and keep 31 and 29 respectively; their stale in-enum
  reservation comments were corrected in the same rebase, so the code-30
  section now lists dashpay#4204 as the only branch still carrying one.
- markdownlint: MD018 (18 occurrences) and MD004 (mixed bullet styles) are
  both clean; MD013 is down to long table rows only.

…otFound

Split out of dashpay#4183 (port of dashpay#4060) per review: the
unmanaged-identity read fixes are conflict-free on v4.1-dev and should
not be blocked on the Keystore rework.

The FFI's blanket Option -> result conversion reports an identity the
wallet does not manage as PlatformWalletFFIResultCode::NotFound (98),
so the Kotlin callers' zero-handle checks were dead and every local
read over an unmanaged identity threw instead of returning absence.

- Dashpay: route getManagedIdentity through
  translateManagedIdentityNotFoundToZero so contacts()/syncState()/
  payments()/sendContactRequest() treat "not managed" as null/empty/
  false; ErrorInvalidHandle still propagates.
- Sweep the remaining dead `== 0L` sites: ManagedPlatformWallet
  .inMemoryIdentityStates (one unmanaged/just-removed id no longer
  throws through the whole listing) and IdentityRegistration
  .contestedDpnsNames (the intended "identity is not managed by this
  wallet" NotFound now actually surfaces).
- platform-wallet-ffi: platform_wallet_get_managed_identity keeps the
  three outcomes distinct (classify_managed_identity_outcome) so a
  stale/removed wallet surfaces ErrorInvalidHandle and never
  masquerades as an unmanaged identity; unit tests pin both arms.
- DashSdkError: name the code (PLATFORM_WALLET_NOT_FOUND_CODE = 98);
  the 98 -> DashSdkError.NotFound mapping is unchanged.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Split out of dashpay#4183 (port of dashpay#4060) per review: the
typed signing error is conflict-free on v4.1-dev and should not be
blocked on the Keystore rework.

The KeystoreSigner "missing key" completion error travels as free text
through Rust and used to come back as an opaque PlatformWallet.Generic
(or WalletOperation) failure. It is now built from a shared
MESSAGE_MARKER constant and recognized on the Kotlin boundary as the
typed DashSdkError.PlatformWallet.SigningKeyUnavailable, so hosts can
route users to key repair instead of showing a generic error. The
marker is only consulted on the catch-all codes (6 / else), so the
dedicated retry-semantics types are never overridden.

Known limitation (kept as-is from dashpay#4183 by request): the discriminator
is message-text-based (message.contains on the marker); a structured
error code across the FFI boundary is follow-up work in the parent PR
line.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…as split

The inherited dashpay#4172 instrumented tests hardcode the legacy KEYS_ALIAS and
the single-alias API; after the alias split the default-policy storage
writes under KEYS_ALIAS_AUTH_GATED, so simulating keypair replacement by
deleting the legacy alias no longer invalidates anything (the CI failure
shumkov diagnosed on storeIfAbsentRederivesWhenTheKeysAliasKeypairWasReplaced).

- WalletStorageOwnershipTest: the replaced-keypair, rejected-blob, and
  no-regeneration probes delete/inspect KEYS_ALIAS_AUTH_GATED; the
  fingerprint-capture test uses encryptForIdentityKeysAlias (and pins the
  captured producing alias); the stale-invalidation-cleanup test uses the
  alias-parameterized deleteIdentityKeysAliasIfCurrentGeneration.
- KeystoreSignerInstrumentedTest: canSignWith rejection simulates
  replacement of the policy alias.

The five DashPayUnlockAndSyncTest / WalletManagerRoundTripTest failures
from PR dashpay#4183's CI run were NOT test or SDK defects: the branch predated
dashpay#4172's workflow hardening (screen_off_timeout / stayon / dismiss-keyguard
+ the hard deviceLocked=0 guard), so the emulator re-locked mid-run and
every MASTER_ALIAS operation threw InvalidKeyException. Rebuilding on the
current base inherits the fixed workflow; those tests are unchanged.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…-> 37 and mirror it (dashpay#4204)

32 is allocated to `ErrorTransactionBuild` (dashpay#4247, also
carried by dashpay#4256) in ERROR_CODE_REGISTRY.md (dashpay#4261). This variant took 32
without a registry row, so the two collide as a hard `E0081: discriminant
value 32 assigned more than once` the moment both land — reproduced on a
real integration merge, not hypothetical. 27-36 are all claimed (27
ErrorShutdownIncomplete via the merged dashpay#4268; 29 dashpay#4184; 31 dashpay#4183; 32/33
37 is the allocation frontier.

The code was also unmirrored on BOTH hosts, which is the more dangerous
half: Swift is exhaustive, so it surfaced as .errorUnknown and lost its
identity; Kotlin fell through to Generic(32), and in any tree carrying
"shielded invite already claimed" as "reservation wallet mismatch". That
matters on the claim-recovery path specifically — the error is raised from
four sites in shielded/operations.rs, three inside the recovery function.

Adds the typed Kotlin PlatformWallet.ShieldedInviteAlreadyClaimed (terminal,
inherited isRetryable = false), the Swift enum case + init(ffi:) arm, a
DashSdkErrorTest assertion pinning 37, and refreshes the stale Swift
reservation comment the registry asked the next toucher to drop.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

… sites

Three more live review findings, all verified against current PR heads.

Rule 5 named a `PlatformWalletResultCode.init(result:)` that does not exist —
`init(result:)` belongs to the downstream `PlatformWalletError`. As written, a
contributor could add the Swift raw case and the typed error handling and still
omit `PlatformWalletResultCode.init(ffi:)`, which is where the generated C
constant is recognised; that switch has a `default:` yielding `.errorUnknown`,
so the omission compiles and silently loses the code's identity before typed
handling sees it. Rule 5 now enumerates all three Swift sites and says how each
one fails: (1) the raw case, (2) the `init(ffi:)` arm — silent, and (3)
`PlatformWalletError` + its `init(result:)` arm — a hard compile error, since
that switch is exhaustive with no `default:`. That third failure is exactly
what dashpay#4204 is sitting on at `d78b940a03`.

dashpay#4196 is no longer blocked. Its head moved to `12492e8c54`, the restack onto
dashpay#4185 is done, dashpay#4185's head `8813e98533` is an ancestor, the trio reads
34/35/36, and the PR is MERGEABLE against v4.2-dev. Verified the numeric
references it owns were carried too: the `StaleReservationToken` KDoc and
`fromPlatformWalletNative` mapping in `DashSdkError.kt` both read 34, and the
V2 broadcast KDoc in `ManagedCoreWallet.kt` reads 34 with the rest symbolic.
`PlatformWalletError::StaleReservation` refers to the code symbolically and
never carried a number. The section is now a resolution rather than an open
item; the account of why the restack was hard is kept, since that was the
substance of the delay.

The code-30 sweep was overstated. "No PR anywhere defines a code 30" is false
for the surveyed heads — dashpay#4185 and dashpay#4256 both did; that was the allocation,
not a competing claim. It now reads "no PR unrelated to dashpay#4185 defines a code
30", which is the claim that actually supports the conclusion. The list of
branches carrying the stale consent-code reservation is corrected to dashpay#4183,
dashpay#4204 and dashpay#4256's pre-renumber rationale (dashpay#4247 was never one of them).

Provenance and the proposed table pick up dashpay#4196's new head. markdownlint
MD018/MD004 remain at 0.

…ingKeyUnavailable (split from #4183) (#4191)

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…-> 37 and mirror it (dashpay#4204)

32 is allocated to `ErrorTransactionBuild` (dashpay#4247, also
carried by dashpay#4256) in ERROR_CODE_REGISTRY.md (dashpay#4261). This variant took 32
without a registry row, so the two collide as a hard `E0081: discriminant
value 32 assigned more than once` the moment both land — reproduced on a
real integration merge, not hypothetical. 27-36 are all claimed (27
ErrorShutdownIncomplete via the merged dashpay#4268; 29 dashpay#4184; 31 dashpay#4183; 32/33
37 is the allocation frontier.

The code was also unmirrored on BOTH hosts, which is the more dangerous
half: Swift is exhaustive, so it surfaced as .errorUnknown and lost its
identity; Kotlin fell through to Generic(32), and in any tree carrying
"shielded invite already claimed" as "reservation wallet mismatch". That
matters on the claim-recovery path specifically — the error is raised from
four sites in shielded/operations.rs, three inside the recovery function.

Adds the typed Kotlin PlatformWallet.ShieldedInviteAlreadyClaimed (terminal,
inherited isRetryable = false), the Swift enum case + init(ffi:) arm, a
DashSdkErrorTest assertion pinning 37, and refreshes the stale Swift
reservation comment the registry asked the next toucher to drop.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…pay#4268 claimed

dashpay#4268 merged `ErrorShutdownIncomplete = 27` into the v4.2-dev
FFI ABI, colliding with this PR's `ErrorStaleReservationToken = 27`. Renumber
the deferred build/broadcast trio to the contiguous block 34-36, which sits
above every code currently claimed by a merged commit or an open PR:

  27  ErrorShutdownIncomplete         MERGED, dashpay#4268
  29  ErrorAssetLockInsufficientFunds dashpay#4184
  31  ErrorSigningKeyUnavailable      dashpay#4183, dashpay#4259
  32  ErrorTransactionBuild           dashpay#4247, dashpay#4256
  33  ErrorTransactionSigning         dashpay#4256

28 and 30 are vacated and return to the free pool. Applied across the Rust
enum, the FFI/JNI rustdoc, the Kotlin mapping + KDoc + tests, and the Swift
mirror (which has no compile-time cross-ABI check, so it was verified by grep).

Also addresses three review suggestions:

* `PlatformWalletInfo::generation` is now `pub(crate)`. It was publicly
  assignable through `state_mut()` / `state_mut_blocking()`, so downstream safe
  code could swap the `Arc` while `PlatformWallet` and `CoreWallet` kept the
  original — splitting the generation identity `Arc::ptr_eq` compares, which
  would make `is_current_generation()` reject a live wallet, turn
  generation-bound reservation cleanup into a no-op, and let teardown exclude
  through a different lifecycle gate than the payments it must fence. All
  construction and mutation sites are already inside the crate.

* `buildSignedPayment` now runs under `opWithCleanupOnCancellation`. Native
  finalization mints the token before the blocking JNI call returns, so
  `withContext`'s prompt-cancellation handoff could discard the completed
  `SignedCoreTransaction` and leave the reservation to the GC Cleaner or the
  TTL. The discarded result is now closed deterministically.

* Native code 26 (`ErrorTransactionBroadcastRejected`) no longer falls through
  to `PlatformWallet.Generic`. It maps to a dedicated
  `TransactionBroadcastRejected` subtype so callers can tell a definitively
  rejected, consumed-and-released payment (rebuild it) from an unrelated
  generic wallet failure, with its non-retry-in-place semantics pinned in
  `DashSdkErrorTest`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>